原文連結：ソフトウェアはなぜバージョンアップしなければならないのか - Qiita

有時在一些官網下載軟體時（例如 node.js 或 Ubuntu ），會發現官方有提供兩種版本，分別是「LTS」和「Current」，其中 LTS 代表 Long Term Support（長期支援），穩定版本確保程式的安全性與可靠性，避免更新可能造成的風險。

軟體除了新增需求、修復 BUG 以外，是否就不需要再進行版本更新了？這篇文章將會介紹為何軟體需要版本更新，以及更新頻率可能帶來不同的結果。

那麼，以下正文開始！

前言

對公司內部基礎設施的運營人員來說，軟體更新雖然看似不起眼，實際卻是相當繁重的工作。

特別是在公司內部署伺服器上運行的軟體，版本升級必須和各個使用該軟體的部門進行調整。

在這種情況下，經常會聽到各個部門傳來這樣的聲音「我們現在很忙，希望延遲更新」或「是否可以跳過這個版本？」。要讓每個部門理解版本升級的價值並不是件容易的事。

本篇文章的目的，就是為了讓上司和各個部門的經理們，明白為什麼我們必須進行版本升級。

軟體的有效期限是 2-5 年

首先必須了解，軟體並不是一套使用到永遠，而是存在一定的有效期限，一旦過了這個期限，它們就會漸漸停止運行。也就是俗稱「什麼都沒做卻停止運作的問題」。

為什麼軟體會停止運作可能有各種各樣的原因。支援軟體運作的中介軟體（Middleware）、編程語言的執行環境（Runtime）、容器（Container）、操作系統（OS），甚至外部伺服器的 API 和認證服務，這些都不斷在變化，如果持續使用舊版本，最終會有某個環節停止運作。

多數軟體都有 Long Term Support（LTS）版本，長期版本通常會提供小型修補程式以支援這些改變，但不會永遠支援舊版本。通常保守支援期限最短 2 年至最長 5 年。因此，版本至少每兩年就必須需要更新一次。

IT 行業是一個流動性較高的行業，但以 2 年頻率為例，對許多員工來說，在職期間至少會經歷一次以上的軟體更新，這是無法逃避的責任。

版本升級越是拖延，難度越會上升

現在，我們已經瞭解到更新版本是無法避免的，但應該以多久的頻率更新才好？更新版本這件事很麻煩，那是否應該拖到 LTS 結束前再執行就好？

為什麼版本升級很麻煩

在討論這個問題之前，可以先思考為什麼版本升級會讓人感到麻煩。

「是因為 UI 改變讓人難以適應嗎？」這確實是一個原因，但人類是能夠適應變化的生物，因此 UI 的變化並不會導致業務停滯不前。雖然多少會有些不滿的聲音，但適應一個月後通常不會有什麼大問題。

實際上，讓人困擾的是「當功能發生變化，使以往的業務無法正常運作」或是「API 規格改變，使協作工具或插件無法使用」的情況。針對這些情況，需要額外花費時間尋找替代功能、調整業務流程、修復協作工具或版本升級等。

一般來說，運行的業務軟體不太可能單獨使用，通常會與其他協作軟體串接數據，或用於業務自動化的 API。

以大規模的軟體而言，想要事先瞭解哪些業務會受到影響是不切實計的。即使試著更新版本，若出現問題，就必須拼命解決以確保不會長時間中斷業務；若無法解決，就只能土法煉鋼，退回到上一個的版本。

像這樣有機會大幅提高工作時數的情況，是版本升級讓人感到麻煩的原因。

版本升級導致業務中斷

版本升級頻率低將導致更新失敗

那麼，維護所需工時會因版本升級頻率而有何變化呢？如果某個業務在版本升級中出現問題，下一個版本並不會自動回復到原本的設計，故障點依然存在。請務必考慮到這一點。

• 版本升級頻率較低：維護工作的發生頻率較低，但每次會影響到多個業務運作，使工作量大幅增加。由於維護人力並不一定充足，可能無法應付大規模的升版工作，導致更新失敗的風險較高。
• 版本升級頻率較高：維護工作的發生頻率較高，但每次影響到的業務量較小，產生的工作量也較少。能夠在較短的時間內修復故障，更新失敗的風險較低。

左圖代表版本升級頻率高的情況，失敗風險較低
右圖代表版本升級頻率低的情況，失敗風險較高

也就是說，如果版本升級頻率較低，將提高更新失敗的機率，反而需要執行多次相同的版本升級。更糟糕的是，在反覆處理更新時，可能又推出了下一個版本，造成另一個故障點，形成一個惡化的循環。若這種情況持續下去，LTS 終將到期，形成任誰也無法維護的軟體化石。

軟體的 LTS 到期將會形成地下城

補充：地下城（Dungeon）在歐美遊戲中已經不僅僅如字面意思一樣指地下的城市或地區，而泛指玩家探險的地區，更接近於迷宮或副本的概念。

若軟體版本升級頻率較低，可能會發生 LTS 支援到期的情況。一旦發生這種情況，將帶來令人沮喪的事實：

• 首先，軟體將停止修復安全漏洞。為了降低安全風險，必須在伺服器外部建立防火牆，由於處於封閉狀態，要進入伺服器進行維護將會變得困難。
• 接下來，其他協作軟體將逐漸停止支援該版本。不但無法新增協作軟體，也無法更新現有的協作軟體版本。當其他軟體的 LTS 到期時，情況將變得更加混亂。
• 很快的，負責維護內部協作工具的人員將不存在。這是因為「不更新 = 幾乎沒有維護工作 = 不需要這份工作」，因此人員會進行調職或者轉職。結果來說，軟體將會變得無法預測的狀態，意即成為地下城。
• 老舊軟體不佳的使用體驗，大量數據導致運作變得緩慢。許多為此感到厭煩的冒險者，曾設法攻克這個地下城，但九成左右都會被黑暗所吞噬，白白浪費寶貴的時間和動力。

最終的結果，可能是由某位大人物一聲令下，展開地下城攻略任務（= Replace Project 取代專案）。這將投入大量工時，包括釐清業務流程、選擇下一個軟體、重新安裝協作工具等等，克服重重問題並進行替換。只要能定期更新，本來是不需投入這些工時的。

為了避免創造地下城

現在，既然已經明白推遲更新可能帶來的風險，接下來讓我們思考該如何避免這種可怕的未來。

每年至少升級一次

首先最重要的，是能夠定期更新。理想情況下，應該每三個月更新一次，最長不超過一年更新一次。提高更新頻率，可有效減少更新時可能出現的問題，並提高更新的成功率。定期更新將更新流程標準化，也會使各部門熟悉操作，知道應該從什麼部分開始檢查。
一旦熟練流程，建議在環境中建立部署協作工具和驗證操作的流程，以便進行操作測試。

統計版本升級所需工時並進行檢視

如果版本升級變成固定工作內容，接下來，應該試著統計與更新相關的工時。如果能預測更新需要多少工時，就能事先向各部門申請工時分配。令人意外的是，若能夠提前預測工時需求，在實際操作時各部門可能會更容易接受。

如果能夠持續進行版本升級，那更新這份工作幾乎不成問題。工時需求主要來自協作工具的維護。由於不能夠無限推遲更新，這些工時需求來源並不是因為更新頻率高，而是由於軟體本身的品質問題，或協作工具的維護與穩定性問題。

如果工時需求過高，建議重新審視協作系統和業務自動化。可將基於 RPA 的自動化工具轉換為基於 API，停止過度的業務自動化，如果軟體本身的穩定性不佳或不重視兼容性，那麼考慮轉移到 SaaS 或進行替換可能也是一種方法。

總結

• 更新軟體版本的原因並不是因為「有推出新功能」。
• 軟體存在 2-5 年的有效期限，超過這個期限，軟體會逐漸地下城化。
• 更新的頻率較低會提升更新的難度，並提高失敗的風險。
• 進行每年至少一次的版本升級，規範版本升級流程，並持續檢視業務，以提供穩定的價值。

最後一點

相較於引入新軟體或進行替換，軟體更新通常被視為一項平凡的工作。

然而，確保軟體更新能夠順利執行，避免軟體地下城化或面臨大規模替換，實際上是非常重要的工作。請負責執行軟體更新的人員應該為這份工作感到自豪。

軟體能夠持續運作並不是理所當然的事情，必須仰賴運營人員持續各種維護工作。希望現場的各位能夠了解，即使沒有釋出所需的新功能，這個業務仍有持續運作的價值。